"[GDS|Entropy]" <gds### [at] hotmailcom> wrote:
> I had a feeling it was C still; long ago I looked at the source when
> considering adding new media scattering methods...then quickly abandoned
> that idea when I discovered how much work would actually be involved with
> the implementation of a new (to pov) algo.. :-|

There are still some areas where the code is quite C-ish, and a few C-ish data
types are still waiting to be "classified", but the coding style has changed
quite dramatically. It now resembles software, not a hack ;P

(Speaking of it - ever seen the NetHack source code? *That* is something to
drive every OO-enthusiast mad... >_<)

> >> http://www.haskell.org/haskellwiki/POV-Ray_SDL_project
> >
> > Yargh! Vade! >_<
>
> Hmm? Sounds like something a norseman might shout just after boarding your
> vessel and just before doing something awful with a large blade. ;-)

Well, I was thinking more of the latin "Vade Satanis!" :P

> > But what you might want to do is:
> >
> > #declare POINT  = 0;
> > #declare COUNT  = 1;
> > #declare RANDOM = 2;
> >
> > #declare Array[i][POINT]  = <...>;
> > #declare Array[i][COUNT]  = <0,0,0>;
> > #declare Array[i][RANDOM] = <0,RRand(RsA, rMin, rMax),0>;
>
> So using different placed in dim2 would be better than having related vector
> flags grouped in their own dimension?

Yeah, because it doesn't waste so much space. See, your approach used N*2*2
array entries - so far! This one only uses N*3 entries. Saves you N entries in
this case. Depending on how many groups you have, and how much they differ in
size, this can quickly get a lot more. E.g., if one group only had a single
entry while another had 8, you'd waste N*7 entries.

> It seems to me that it could become confusing and require code rewrites (for
> grouping of like flags/misc) if one uses only 2d when thy might have a set
> of flags in d2 for say, branching, child nodes, etc.. and more for
> interpolated vectors or the like. It also seems that using those additional
> attributes could become messy if they are just all over the place.

You cannot avoid *some* kind of mess with POV's SDL.

> > Yes, maybe the standard include files could use an overhaul, too.
>
> Agreed. Especially the textures, a lot of them kinda suck...like the
> metals...and glasses...

Most of them date back to the pre-Radiosity era; that's why they have ambient in
them, and that's why they do suck indeed.

> I'd like to see a nice influx of textures created by the community. Waters,
> glasses, metals, stones....there are so very many great ones I've seen used
> here.

I guess the POV team would agree. The major problem is that although the POV
community is obviously alive and kicking, nobody seems to see that here's where
they could help the dev team quite a lot.

People possibly don't get involved because they think developing POV 3.7 is all
about C++ programming. Well, it is not: POV 3.7 will need various updates to
the documentation. POV 3.7 would greatly benefit from a major overhaul of the
include files. And so on. Someone just needs to take the lead, team up with
others here to get those things done, and in the end lay the results in front
of the dev team to get it all approved. All the while the dev team can
concentrate on C++ coding.

I took the step from a normal POV user to a code contributor because I wanted
both symmetric multiprocessing *and* radiosity, which wasn't available end of
last year.

If you want better textures, why not take a step forward, too, and become a
contributor of texture include files? You don't even need to do all on your
own. Beg, steal or borrow whatever you think should be part of a "POV starter
pack". Or hack up some macros you think every POV user should have at their
disposal - you seem to be darn good at it, except for some lack of experience
(but really making up for it by a strong will to experiment, and actually
benefiting from that lack by looking at things from a different and fresh
perspective).

You know, becoming a contributor to the POV package is not difficult: Just pick
a thing you *want* improved and think you *could* improve if given the chance -
then step forward here in the newsgroups, making clear that you would like to
have a go at it, and I'm quite sure you will *get* that chance.

> Maybe once I get my macro suite to a good place, I could get the snowball
> rolling on this..assuming they would actually use any files I created.

Do so. And expect them to do appreciate your contributions.

> > .... and a new SDL grammar, as we're on it.
>
> Yes. My vote is cast with using more common C-ish things, as those who
> program will quickly adapt, and those who don't will spend the same amount
> of time learning as before, but will also be familiar with java/c#/c++ ish
> languages without even knowing it. Good for everyone.

Yeah, that would (roughly) be the direction I'd suggest, too. I guess there's no
"syntax family" as big as the "C-alikes", ranging from C over C++, Java, C# to
JavaScript (so web designers should be familiar with it as well) or even some
unix shells.

However, for some statements I would take a radically different approach. For
instance, although I'm perfectly accustomed to it, I never got to really like
the C-style 'for' loops. For my taste, "for" loops should always iterate
linearly (99% of all C 'for' loops do anyway); and there should be a "foreach"
loop to iterate over data containers.

> > For the job we're doing, octrees would come in handy, too.
>
> And hash tables(with a good many hashing methods), and heaps(with a lot of
> heap types), and a proof of the riemann hypothesis, and and and ;-D

I don't care about the riemann hypothesis, and I don't think we need dedicated
heaps, but hash tables might be useful at times ;)

But I really wasn't kidding: As we're dealing with objects in 3D space, I think
really the most "natural" data structures for a lot of problems would indeed be
spatial subdivision trees, and octrees would probably the most widely applicable
of those.

> Indeed. I'd take any improvement at this point.
> Any idea why they never did that?

Yes: C.

You don't think about such stuff as long as you're coding straightforward
classic C. In that language, you don't mix data types. Real C programmers just
don't think OO. It's almost a break of style that there is a generic object{}
statement.

Fortunately, the dev team doesn't have any real C programmers among their ranks
anymore (as far as I know); the internals are getting migrated to C++; and it's
probably about time for the SDL to head for OO, too.

Post a reply to this message